REMARKS 

By this amendment, no claims have been added or cancelled. Claims 1,5,7, 16, 20, 22 
have been amended. Amendments to the claims are made herein without acquiescence to the 
position of the Office Action or prejudice to pursue the claims as originally filed in a 
continuation application. Hence, Claims 1-32 are pending in the application. 



SUMMARY OF THE REJECTIONS 

Claims 1-32 were rejected under 35 U.S.C. § 102(e) as allegedly being unpatentable 
over Viswanadham. 

The rejections are respectfully traversed. 



THE PENDING CLAIMS ARE PATENTABLE OVER VISWANADHAM 

As explained in further detail below, it is respectfully submitted that each of the pending 
claims recites at least one element that is not disclosed, taught, or suggested by the cited art. 



A. CLAIMS 1 -4, 16-19, AND 31-32 

Claim 1 recites the features of: 

"A machine-implemented method for sending packets, comprising the steps of: 
communicating, from an application to an operating system, a policy for 
manipulating packets, 

wherein the policy specifies at least one of (a) redirection needs of the 
application, (b) replication needs of the application, (c) packet 
aggregating needs of the application, and (d) packet splitting needs of the 
application; and 

in response to receiving packets at the operating system, the operating 
system modifying the packets based on the policy without 
intervention of the application." (emphasis added) 
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At least the above-bolded features of Claim 1 are not disclosed, taught, or suggested by 

Viswanadham. 

The approach for Claim 1 provides an advantageous method for sending packets from 
an origin to a destination. In the approach of Claim 1, a policy for manipulating packets is 
communicated from an application to an operating system. For example, the application may 
be a firewall or a proxy server. The policy specifies at least one of (a) redirection needs of the 
application, (b) replication needs of the application, (c) packet aggregating needs of the 
application, and (d) packet splitting needs of the application. In response to receiving packets 
at the operating system, the packets are modified based on the policy without intervention of the 
application. Advantageously, when the operating system receives packets intended for another 
recipient, the operating system may modify the packets based on the policy without further 
involvement by the application. Thus, the time and resources involved in context switching 
between the operating system and the application may be avoided. 

Such an approach is in sharp contrast to the approach of Viswanadham. Viswanadham 
is directed to a switching device that is configured to perform routing at OSI layer 3, switching 
at OSI layer 2, and supporting multiple interfaces at OSI layer 1. To the extent that the 
approach of Viswanadham teaches a policy for manipulating packets, that policy is maintained 
by a software application. Importantly, the Viswanadham reference is directed towards 
implementing functionality performed by integrated circuits, a reduced instruction set (RISC) 
processor, and software, but is not directed towards implementing functionality in an operating 
system. Not only does the entire disclosure of Viswanadham fail to suggest how an operating 
system may be used in the approach of Viswanadham, but the phrase "operating system" does 
not appear once in the reference. 

The Office Action argues: 
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it is inherent that the policy for manipulating packets must be contained in the 
software application and that the operating system [e.g., the RISC processors 10, 
12] performs that policy through the instructions in the software application. 

The Applicant whole-heartedly agrees with the above statement, in that the prior art 
teaches that (1) operating systems perform actions at the direction of applications, and (2) 
traditionally, the policy for manipulating packets is contained in the application. In fact, this is 
one of the problems that the Applicant's invention solves. Specifically, because the policy for 
manipulating packets is contained in the application in the prior art, time and resources must be 
devoted in context switching between the operating system and the application when the 
application makes calls to enforce the policy. On the other hand, Claim 1 defines an approach 
where this context switching may be avoided due to the claimed features expressly recited 
therein. 

In view of the fundamental differences between the approach of Claim 1 and that of 
Viswanadham, the element of "communicating, from an application to an operating system, a 
policy for manipulating packets" is clearly not disclosed, taught, or suggested by Viswanadham. 
The portion of Viswanadham cited to show this element (Col. 2, lines 60-65) merely states, in 
toto: 

Preferred software functions include: dynamic Internet Protocol (IP) routing, 
(e.g., RIP, RIPv2 ? OSPF); layer 2 support (e.g., 802. ID STP); configuration 
support (e.g., enable/disable Layer 2 or Layer 3 support on per-port basis; ports 
can be grouped into broadcast domains; flexible subnet configuration); network 
management; (e.g., SNMP, HTML, Telnet, TFTP, DHCP support). 

Significantly, the portion of Viswanadham cited above lacks any discussion of 
communicating anything from an application, let alone communicating, from an application to 
an operating system, a policy for manipulating packets as required by this element. 
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Equally important is the observation that the cited portion of Viswanadham lacks any 
discussion of the concept of an operating system. At best, the cited portion of Viswanadham 
lists several examples of functions of software that is stored in a RISC processor of a switch 
element, but the cited portion, as well as the entire disclosure of Viswanadham, lacks any 
suggestion of an operating system that receives a policy from an application. 

While the Applicant agrees with the Office Action that the approach of Viswanadham 
may implicitly involve the use of an operating system, there is no suggestion in Viswanadham 
of an application communicating a policy for manipulating packets to an operating system. 
Further, the Applicant agrees with the Office Action's observation that, in prior art systems, "it 
is inherent that the policy for manipulating packets must be contained in the software 
application." Thus, since the policy for manipulating packets must be contained in the software 
application in prior approaches, the implicit use of an operating system cannot be analogous to 
"communicating, from an application to an operating system, a policy for manipulating 
packets" as featured in Claim 1. 

For at least the above reasons, it is respectfully submitted that the element of 
"communicating, from an application to an operating system, a policy for manipulating 
packets" is not disclosed, taught, or suggested by Viswanadham. 

Claim 1 also recites the feature of "in response to receiving packets at the operating 
system, the operating system modifying the packets based on the policy without intervention of 
the application." The Office Action acknowledges that Viswanadham teaches the use of a 
policy for manipulating packets contained in the software application. As a result, when 
packets are received by switching device of Viswanadham, the packets cannot be modified by 
the operating system based on the policy without the intervention of the software application 
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that contains the policy. As a result, this feature also cannot be disclosed, taught, or suggested 
by Viswanadham. 

As one or more elements featured in Claim 1 are not disclosed, taught, or suggested by 
Viswanadham, Claim 1 is patentable over the cited art and is in condition for allowance. 

Claim 16 contains limitations similar to that of Claim 1, except that Claim 16 is recited 
in computer-readable medium format. Consequently, for at least the reasons given above with 
respect to Claim 1, it is respectfully submitted that Claim 16 is patentable over the cited art and 
is in condition for allowance. 

Claims 2-4, 17-19, and 31-32 are dependent claims, each of which depends (directly or 
indirectly) on one of the claims discussed above. Each of Claims 2-4, 17-19, and 31-32 is 
therefore allowable for the reasons given above for the claim on which it depends. In addition, 
each of Claims 2-4, 17-19, and 31-32 introduces one or more additional limitations that 
independently render it patentable. 

For example, Claims 31 and 32 feature the elements of "communicating, from the 
application to the operating system, a second policy for manipulating packets" and "at the 
operating system, modifying a second set of packets based on the second policy while the 
operating system is still configured to modify the first set of packets based on the first policy." 
No portion of Viswanadham discloses, teaches, or suggests this combination of elements. 



B. CLAIMS 5-6 AND 20-21 

Claim 5 recites the features of: 

"A machine-implemented method for sending packets in a computer system, 
comprising the steps of: 

communicating, from an application to hardware, a policy for manipulating 
packets, 
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wherein the policy specifies at least one of (a) redirection needs of the 
application, (b) replication needs of the application, (c) packet 
aggregating needs of the application, and (d) packet splitting needs of the 
application; and 

in response to receiving packets at the hardware, the hardware modifying 
the packets based on the policy without intervention of the 
application." (emphasis added) 

At least the above-bolded features of Claim 5 are not disclosed, taught, or suggested by 
Viswanadham. 

The approach for Claim 1 provides an advantageous method for sending packets from 
an origin to a destination. In the approach of Claim 1, a policy for manipulating packets is 
communicated from an application, e.g., a firewall or a proxy server, to hardware, such as a 
router. The policy specifies at least one of (a) redirection needs of the application, (b) 
replication needs of the application, (c) packet aggregating needs of the application, and (d) 
packet splitting needs of the application. In response to receiving packets at the hardware, the 
hardware modifies the packets based on the policy without intervention of the application. 
Advantageously, when the operating system receives packets intended for another recipient, the 
hardware may modify the packets based on the policy without further involving the application. 
Thus, the time and resources involved in context switching between the hardware and the 
application may be avoided. 

In view of the fundamental differences between the approach of Claim 1 and that of 
Viswanadham, the element of "communicating, from an application to hardware, a policy for 
manipulating packets" is clearly not disclosed, taught, or suggested by Viswanadham, The 
portion of Viswanadham cited to show this element (Col. 2, lines 60-65; FIG. 10A, hardware 
block, Col. 15, lines 49-51) discusses functions that may be performed by an application, but 
lacks any discussion of hardware modifying packets without intervention of an application. 
The Office Action also cites the Transmit Queue Management Block 154 to show this element, 
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but while the Transmit Queue Management Block 154 is a hardware block for managing 
transmit queue functions for switch circuit 20, Viswanadham lacks any suggestion that the 
Transmit Queue Management Block 1 54 receives a policy from any entity, let alone an 
application. Additionally, the cited portion of Viswanadham lacks any discussion of 
communicating anything, let alone a policy for manipulating packets. As a result, this element 
is not disclosed, taught, or suggested by Viswanadham. 

Further, Claim 5 also recites the feature of "in response to receiving packets at the 
hardware, the hardware modifying the packets based on the policy without intervention of the 
application." However, there is no suggestion in the cited portion of Viswanadham of 
hardware, such as the Transmit Queue Management Block 154, modifying packets based on a 
policy without intervention of an application. For example, the portion of Viswanadham cited 
to show this feature (Col. 3, lines 1-4) merely discusses a variety of software applications. 
While these software applications may perform actions in conjunction with hardware, there is 
no suggestion in this portion of Viswanadham of hardware modifying packets based on a policy 
without the intervention of an application. As a result, this element also cannot be disclosed, 
taught, or suggested by Viswanadham. 

As at least one element featured in Claim 5 is not disclosed, taught, or suggested by the 
cited art, Claim 5 is patentable over the cited art and is in condition for allowance. 

Claim 20 contains limitations similar to that of Claim 5, except that Claim 20 is recited 
in computer-readable medium format. Consequently, for at least the reasons given above with 
respect to Claim 5, it is respectfully submitted that Claim 20 is patentable over the cited art and 
is in condition for allowance. 

Claims 6 and 21 are dependent claims, each of which depends (directly or indirectly) on 
one of the claims discussed above. Each of Claims 6 and 21 is therefore allowable for the 
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reasons given above for the claim on which it depends. In addition, each of Claims 6 and 21 
introduces one or more additional limitations that independently render it patentable. 

C. CLAIMS 7-15 AND 22-30 

Claim 7 recites the features of: 

"A machine-implemented method for sending messages, comprising the steps of: 
creating, by an application, an aggregate message from individual messages 

that are to be sent using an operating system service; 
transmitting the aggregate message from the application to an operating 

system with a system call; 
within the operating system, dividing the aggregate message back into individual 

messages; and 

transmitting the individual messages using the operating system service, 
wherein at least one of the individual messages is sent to a different recipient 
than another of the individual messages." (emphasis added) 

At least the above-bolded features of Claim 7 are not disclosed, taught, or suggested by 
Viswanadham. 

The approach for Claim 1 provides an advantageous method for sending messages. In 
the approach of Claim 1, an aggregate message is created, by an application, from individual 
messages that are to be sent using an operating system service. The aggregate message is 
transmitted from the application to an operating system with a system call. Within the 
operating system, the aggregate message is divided into individual messages. The individual 
messages are transmitted using the operating system service. At least one of the individual 
messages is sent to a different recipient than another of the individual messages. 
Advantageously, using the approach of Claim 7, a plurality of individual messages may be 
transmitted from an application to an operating system in a single system call, thereby reducing 
the number of context switches that must be performed. 

Such an approach is in sharp contrast to the teachings of Viswanadham. The portion of 
Viswanadham cited to show the above-bolded features (Col. 7, line 32-Col. 8, line 3; Col. 24, 
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lines 6-10; and Col. 21, lines 43-45) discusses splitting a frame of data into smaller portions, or 
"slices," of data, and subsequently reconstituting the original frame of data from the slices of 
data. The Office Action position appears to rest on the understanding that "it is inherent that 
groupings of packets can be bigger or smaller than the 64 byte slices, but the packets must be 
reconstituted in the correct order for unicast/multicast/broadcast to the respective ports via the 
FE (Office Action, page 10)." Assuming, arguendo, that this is true, numerous features of 
Claim 7 are still not disclosed, taught, or suggested by Viswanadham. 

Claim 7 requires that the aggregate message is created by an application from individual 
messages that are to be sent using an operating system service, the aggregate message be 
transmitted from the application to an operating system with a system call, and the aggregate 
message is divided within the operating system back into the individual messages. 
Viswanadham fails to teach or suggest these features, and the position of the Office Action does 
not explain how Viswanadham teaches or suggests these features. 

To illustrate, the transmit slice buffer and the receive slice buffer of Viswanadham 
reside at the same level of the switch circuit 20. However, in Claim 7, the aggregate message is 
created by an application and the aggregate message is divided within the operating system. 
The argument of the Office Action ignores these claimed features of Claim 7. 

For example, Claim 7 features the element of "creating, by an application, an aggregate 
message from individual messages that are to be sent using an operating system service." The 
cited portion of Viswanadham lacks any suggestion of an application creating an aggregate 
message. Consequently, this element is not disclosed, taught, or suggested by Viswanadham. 

The cited portion of Viswanadham also fails to discuss the concept of transmitting 
anything to an operating system, let alone transmitting an aggregate message from the 
application to an operating system with a system call. At best, the cited portion of 
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Viswanadham merely describes sending slices (portions of a frame) from one buffer to another 
buffer. However, the slices of Viswanadham are not transmitted from an application to an 
operating system in a system call. Thus, the cited portion of Viswanadham fails to disclose, 
teach, or suggest the element of "transmitting the aggregate message to an operating system 
with a system call" featured in Claim 7. 

Consequently, for at least the above reasons, it is respectfully submitted that one or 
more elements featured in Claim 7 are not disclosed, taught, or suggested by Viswanadham. 
Thus, it is submitted that Claim 7 is patentable over the cited art and is in condition for 
allowance. 

Claim 22 contains limitations similar to that of Claim 7, except that Claim 22 is recited 
in computer-readable medium format. Consequently, for at least the reasons given above with 
respect to Claim 7, it is respectfully submitted that Claim 22 is patentable over the cited art and 
is in condition for allowance. 

Claims 8-15 and 23-30 are dependent claims, each of which depends (directly or 
indirectly) on one of the claims discussed above. Each of Claims 8-15 and 23-30 is therefore 
allowable for the reasons given above for the claim on which it depends. In addition, each of 
Claims 8-15 and 23-30 introduces one or more additional limitations that independently 
render it patentable. 
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CONCLUSION 

For the reasons set forth above, it is respectfully submitted that all of the pending claims 
are now in condition for allowance. Therefore, the issuance of a formal Notice of Allowance is 
believed next in order, and that action is most earnestly solicited. 

The Examiner is respectfully requested to contact the undersigned by telephone if it is 
believed that such contact would further the examination of the present application. 

Please charge any shortages or credit any overages to Deposit Account No. 50-1302. 

Respectfully submitted, 

HICKMAN PALERMO TRUONG & BECKER LLP 




Christopher J.^Brokaw 

Reg. No. 45,620 

Date: November 7, 2005 



2055 Gateway Place, Suite 550 
San Jose, CA 95110-1089 
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Facsimile: (408)414-1076 
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